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(54) A dynamic distributed multicast routing p 

(57) The distribution of multicast information in a 
communications network formed from a plurality of com- 
munications nodes, e.g.. ATM switches, is enhanced by 


mtocof 

providing an efficient mechanism for routing a request 
to pin a multicast connection scan originator of the mul- 
ticast and an efficient mechanism for then connecting 
the reauester to the multicast connection. 




KELP OF THE tNVEWTIQW: 



The invention relates to data networks and more s 
particularly relates to a multicast protocol for locating, 
joining and leaving a multicast group that is receiving 
particular information. 

BACKGROUND Ot" THS INVENTION: fc 



Presently, a ossr associated with a multimedia ter- 
minal, e.g., a conventional workstation or PC, may enter 
a request via the terminal to participate m a particular 
event, e.g. , a lecture, audio/video conference, televised lS 
speech, etc., that is being provided by a node, e.g., a 
packet switch, in a digital network. The event is typically 
associated with some type of identifier, i.e., group iden- 
tifier (e.g., 800 number or conference bridging number 
in conventional telephone networks) so thai a user who so 
wants to participate in the event may identify the event 
in a request that the user submits to his/her terminal 
The user's terminal then forwards the request to an as- 
sociated serving node within the digital network. A group 
identifier may represent a collection of users who are 2S 
interested in particular information associated with the 
event. (Note that group identifier is different from an 
identifier thai is used to identify a particular user.) Typi- 
cally, the membership associated with a group identifier 
may be dynamic such that a member may join and leave so 
the group at any time. Also, there is no restriction on the 
physical location of multicast group members who may 
or may not be at the same physical location. The net- 
work maintains information relating to the group and typ- 
ically does this by constructing a network directory 35 
which fs used to track the connectivity of active mem- 
bers. That is. a serving node submits the group identifier 
to the network directory The directory, in turn, returns 
the address of the nearest node which it can join, The 
sewing node then sends a request to join the multicast AO 
group to the identified node. A node that joins or leaves 
a multicast group must notify the directory so that it can 
update the membership information. Unfortunately, 
membership may change so frequently that manage- 
ment of such a directory may become costly and ineffi- 
cient. 

The network may also maintain such membership 
by constructing a multicast server in the network. Data 
that is sent by a user is then first delivered to the server, 
which, in turns, delivers the information to ail other mem- so 
bers in the multicast group. Although ihss approach ap- 
pears to be simple so implement it, nevertheless, may 
lead to a single point of failure in the event that the server 
fails. Moreover, this approach does not use the network 
resources efficiently, since user data has to be sent to $$ 
the server. 



The foregoing is addressed and the relevant an is 
advanced by providing an efficient and scaleable mech- 
anism for a data network So maintain multicast group in- 
formation in a distributed fashion m which any node in 
the network may automatically locate, josh and ieave a 
multicast group. The mechanism is distributed so that a 
single node has to maintain complete information about 
the other participants of the multicast group. In particu- 
lar, in accordance with an illustrative embodiment o? The 
invention, a network node enters a request to pin a mul- 
ticast group, by constructing at least one routing tree 
formed f rom selected paths to each of a number of other 
nodes identified in the tree and sending a tind message 
identifying the multicast group to the selected nodes in 
accordance with the routing tree. In response to receipt 
of a message identifying the nearest node connected to 
the multicast group, the requesting node then simply 
sends a join message to the identified node to ioin the 
multicast group. 

These and other aspects of the claimed invention 
are disclosed in the ensuring detailed description, ac- 
companying drawings and claims. 

BRIEF DESCftiPNCN OF THE DRAWINGS: 



in the drawing: 

FiG. t shows a communications network in which 
the principles of the invention may be practiced: 

FiG. 2 illustrates a routing tree rooted at a particular 
one of the nodes of FIG. 1 : 

FIG. 3 shows a state diagram illustrating the oper- 
ation ot a node in accordance with the principles of 
the invention: 

FIGs. 4-9 are respective expanded versions of the 
operations states shown in FIG. 3, and 

FIGs. 1 0-1 5 illustrate the operation of the principles 
of the invention in an illustrative hierarchical net- 
work. 

PET AS LEO DESCRIPTION: 

Our inventive protocol supports what we call a "Par- 
ticipant-Initiated Josn", in which a node initiates a re- 
quest to join a multicast group and. in doing so. deter- 
mines the networK path that is to be used to join the mul- 
ticast The protocol -has two phases. We call the first 
phase the "Find" phase, since it is the requesting node 
that determines the identity of the nodes that are already 
on the multicast tree. We eaii the second phase the 
Mom" phase, since the requesting node attempts to join 
the nearest node that is already on the multicast tree, in 



the Find phase, a node that wants to join the multicast 
group originates a REQUEST message and sends it to 
all of its neighbors on the shortest path tree rooted at 
the requesting node. A neighbor that receives the mes- 
sage then forwards it downstream to its neighbors along 
the iinks of the shortest path tree rooted at the originat- 
ing: node. This process continues until the REQUEST 
message reaches either a node that is already on the 
multicast tree or a leaf node of the shortest path tree 
rooted at the originating nods {i.e. , the node that has the 
sought-after multicast information.) Each node that is al- 
ready on the multicast tree replies to the request, with 
the cost parameter set to 0. The leaf nodes that are not 
on the multicast tree reply to the request with the cost 
parameter set to -1 . On receiving all of the replies to the 
message, a node determines the nearest node and for- 
wards the REPLY message trom the nearest node up- 
stream towards the originator of the REQUEST Before 
doing so. the node updates the cost function to reflect 
the cost from this node to the nearest node. The origi- 
nator receives aii the replies and determines the nearest 
node. This ends the Find phase. In the Join phase, the 
requesting node determines the path to the nearest 
node and sends a JOI N-REQ message. The determined 
path is inserted in the message so that an intermediate 
node does not have to make the same determination. 
The nearest node (having the sought-after information) 
replies with a JOI.N-ACK message and ail the nodes in 
the path become a branch of the multicast tree 

An illustrative example of the foregoing is shown in 
FIG 1 , tn which sought-after multicast information is as- 
sumed to be a multimedia event ISO,, e.g., a televised 
lecture, fvfuitimedia signals characterizing the multime- 
dia event are supplied to node 105, which may operate 
as a conventional video server for the purpose of sup- 
plying the video signal in the form of digital signals to a 
user who has entered a request to receive a copy of 
such signals via network 100 formed from data nodes 
105, 110, 115, 120, 125, 130 and 135. In an illustrative 
embodiment of the invention, each of the nodes may be, 
for example, a conventional ATM switch. Assume that a 
user associated with workstation 1 70 in a conventional 
manner enters a request via a keyboard (not shown) to 
view the event on monitor 175, in which the request in- 
cludes an identifier associated with the multimedia 
event. The request, however does not contain the iden- 
tity {e.g., address) of the source of the multicast infor- 
mation. Workstation 170, in response to receipt of the 
request, converts the request into a form expected by 
associated network node 125, afso shown as the E 
nods. As an aspect of the invention, network 100 does 
not Include a directory identifying the information that is 
respectively supplied by the network 100 nodes. Ac- 
cordingly, to locate the node that has the multicast in- 
formation, node 125 will poll each ot the other network 
100 nodes. Before doing so, however, nods 125 con- 
structs a tree formed trom selected paths to each of the 
other nodes, in which the selection is based on prede- 



termined parameter, for example, cost, number of hops, 
etc. In an illustrative embodiment of the invention, cost 
is characterized by a weight value. Such weight values 
are shown in parentheses in FIG. 1 and are used, as 

■5 mentioned, to identify a least cost path/routs. For exam- 
ple, if node i20 (D) needs to send a message to node 
f 05 (A), then node 120 will likely send the message via 
node 110 (8) since the sum of she weights associated 
with the links in that path is lass than the sum of the 

10 weights associated with the links in the via node 1 1 5 (C) 
path, i.e., (5) + 0) < (6) + (3). 

Thus, in accordance with known techniques, node 
1 25, in the "find" 1 phase, constructs a path tree and uses 
that tree to control the routing of a message to locate a 

is node that has the requested multicast information, i.e., 
the televised event 150. An example of such a tree Is 
illustrated in FIG. 2. Node 1 20 thus sends a "Find" mes- 
sage to node 1 35 (G) and to node 120(D) in accord with 
the tree. The "Find" message includes, inter alia, the ad- 

so dress of the message originator, identifier associated 
with the sought-after information, a request for the iden- 
tity of the nods that has the sought-after information. 
The message may also inciude information characteris- 
ing the constructed path tree. Accordingly, then, upon 

sb receipt of the message, node 1 35 returns a Reply mes- 
sage with the cost parameter set to -i. Although node 
1 20 does not have the sought-after information, it does 
not discard the message since the path tree indicates 
that the message should be Individually routed to nodes 

20 no, 115 and 130, as shown in FIG 2. Similarly, when 
the message reaches node 110, the node does not dis- 
card the message {even though it does not have the 
sought-after information), but forwards it to node 105 
{A), Since, it is assumed that node 105 has the sought 

3$ after information, then it responds to the received mes- 
sage by returning to node 125 a reply message contain- 
ing the identity (address) of node 105 and with the cost 
parameter set to 0. 

Upon receipt of the latter message, node 1 25 enters 

40 the "Join* phase, as discussed above. In this phase, 
node 125 constructs the shortest path to node 105 and 
sends a Join message containing the node i 25 address 
with a request to join the multicast of the identified event. 
Referring to FIG 2, it is seen thai, such path would 

*5 be via nodes 110 and 120. rather than via nodes 115 
and 120. Node 105 returns a Join-ACK and then starts 
supplying the televised event to node 125 via the deter- 
mined path. When nodes 110 and 120. which are in the 
path of the multicast, start receiving the multicast mfor- 

so mat ion then they note in their respective internal mem- 
ories that they also have such information. 

Assume at this point that a user associated with 
node 1 30 also wishes to receive the multicast and enters 
a request tor that information. Similarly, node 130 con- 

ss structs a teasi-cost path tree and launches its own find 
message in accordance with the tree (not shown). When 
the message reaches node 1 20, it responds with a reply 
message to node 1 30 indicating that it has the informa- 



tlon. As discussed above, node 1 30 accumulates the re- 
ply messages and then determines from those message 
which of the nodes having the sought-after information 
is closest to node 130. in the present illustrative exam- 
pis, the closest node for the desired purpose would be 
node 120. Accordingly, then node 130 may join the mul- 
ticast by sending a Join message to node 120, rather 
than to node 1 05. Thus, when node 1 20 receives a pack- 
et ot such information from node 110, it sends a copy to 
node 1 25 and a copy to node 1 30. 

If at this point, the user at workstation 1 70 enters a 
request to terminate receipt of the multicast, then node 
1 25 forms a "Leave" message and sends the message 
to node 120 in accordance with the constructed path 
tree rooted at node 125. When node 120 receives the 
message, it stores the message in iocai memory and 
terminates the supplying ot the multicast information to 
node 1 25 but wilt continue supplying that information as 
it is received to node 130. If prior to the end of the tele- 
vised event, node 130 launches a "Leave" message., 
then node 120, in response to thai message and in re- 
sponse to having no other receiver lor the multicast, 
sends a message to node 11 (Ho terminate the supplying 
of the moittcasJ to node 1 20. Similarly, node 1 1 0 sends 
a similar message to node 1 05 if it has no other receiver 
for the multicast information, 

A situation could arise in which a node receives, at 
about the same time (concurrently), Find messages 
from a plurality of nodes, e,g , two nodes To handle this 
situation and preserve the correctness of !he distributed 
protocol, a node, e.g.. node 125. appends a time stamp 
to a Find message. In this way, if a node, e.g.. node D, 
receives concurrently "Find" message from nodes 125 
and 1 30, then if processes the Find message bearing 
the earliest time stamp and returns a Reply message to 
the node, e.g., node 130. that launched the Find mes- 
sage bearing the latest time stamp. Then, when the least 
cost multicast path is established from node ! 05 to node 
1 20, then node 1 30 launches a Find message after .wait- 
ing a random (or a predetermined) period of time and 
then proceeds as discussed above. 

in an illustrative embodiment of the invention, the 
principles of the invention are embodied in a state ma- 
chine which is implemented in each network node for 
each multicast group. An illustrative example of such a 
state machine is illustrated in FIG. 3 and is composed 
of five major states, namely IDLE 301 , WAiT 302, TEN- 
TATIVE 303, ACTIVE 304 and RETRY 305. Before dis- 
cussing FIG. 3, it would be best to review the different 
message(s) that may be sent by a node attempting to 
pin a multicast and the messagefs) that are sent by the 
other nodes in the network in response to a request to 
join a multicast session. Briefly, a node that wants So join 
a multicast free/session sends a REQUEST message, 
in the manner discussed above. The header of the re- 
quest message contains, inter alia, the Identity of the 
multicast information, sender ID, and time-stamp, (it 
may also contain a retry count.) A request message can 



only be originated by a node that is in the IDLE state. A 
node sends a REPLY message in response to receipt 
of a REQUEST message. A REPLY message includes 
the header information of the REQUEST message and 

$ an associated cost parameter which Identifies the cost 
of the shortest path from the current node to the nearest 
node that is already on the tree. The cost is updated as 
the REPLY moves from one node to another node. The 
cost Is set to -1 if there Is no ACTIVE node on that par- 
se ticular path. A node sends a RETRY message if it de- 
termines that another request is already being proc- 
essed, as discussed above. The request with the earlier 
time-stamp is allowed to continue whiie a RETRY mes- 
sage is sent to the originator of the request having the 

15 iater time stamp, as mentioned above. A node sends a 
JG1N-REQ message when it wants to join the multicast 
session/tree. The path to the nearest node is encoded 
within this message. An ACTIVE node sends a JOhM- 
ACK message in response to receiving a JOIN-REQ 

so message. The receipt of this message indicates that a 
node is on the multicast tree. A node sends a LEAVE to 
an ACTIVE neighbor node when it wants to ieave the 
multicast session/tree. 

Turning then to FIG, 3, Briefly, in the IDLE state a 

25 node has no information pertaining to the multicast in- 
formation (or tree). A node enters the WAIT state after 
it has sent/forwarded a REQUEST message and is wait- 
ing for a response A node enters the TENTATIVE state 
after it has sent/forwarded a JOIN-REQ message io- 

30 wards the nearest node that is already on the multicast 
tree. In this state, the node is waiting for a JOIN-ACK 
message. A nods enters the ACTIVE state when it joins 
a multicast session {i.e., if <s on the multicast tree. A 
node reaches this state when it receives a JOIN-ACK 

■is message from a node that is already on the tree. A node 
in the ACTIVE state may also maintain the tree-based 
information regarding all the links that are incident on it 
and belong to the tree. However, the node does not 
maintain any state information about new requests fo 

*o pin the tree A node reaches the. RETRY state when it 
is the originator of a REQUEST to join a multicast tree 
and receives a RETRY message via one of the links of 
the tree. In this state, a node does not have to maintain 
any state information relating to other requests. Also, 

4 & the node waits for a random period of time before re- 
sending the original REQUEST If may also track the 
number .of REQUEST messages that it sends. 

An expanded version of the IDLE state is shown in 
FSG, 4, As mentioned above a node initiates a RE- 

so QUEST message when it is in the IDLE state. 

A node in this state only can initiate a REQUEST 
message. A REQUEST message is idemified using the 
tuple <senderlD,time-stamp,retry-count>, where send- 
er ID is the ID of the node that is the originator of the 

55 message, time-stamp is the value of a counter at the 
senderiD and retry-count is the number of attempts the 
nods nas made to join the free. The retry-counS is initially 
0. The initial REQUEST message Is forwarded on ail the 



links via the shortest-path tree rooted at the originating 
node. The node then enters the WAiT state. The follow- 
ing actions are taken whan the node receives either a 
REQUEST message (action path 401) )or JOIM REQ 
message (action path 402). For example, assume that 
a REQUEST massage is received from node B, and 
therefore contains the tuple <SD B ,CNTR 8 , RC 8 >. Then 
the receiving node takes the following actions: 

If the message is not on the shortest path , then send 
a REPLY wsth cost = -1 towards the originator. Else, 
update the time stamp (local counter). 

Save the state information of the message. 

Forward the REQUEST message. Change State = 
WAiT. 

If no available link, send REPLY with cost = -i. State 
- IDLE. 

if a JOIN-REQ message is received from node 8, 
then the receiving node proceeds as follows: 



its links, than the node takes the following actions (path 
502): 

Ignore the REPLY message if it does not contain 
s state information. 

If not the iast reply, then store the cost information 
and wait for other reply messages. 

io If the last REPLY, then determine best message fay 
minimizing Ihe {cost fseld of message + link cost). 
Then forward the best message towards the origi- 
nator of the REQUEST after updating cost. Change 
state = IDLE. 

is 

If originator of REQUEST message, then compute 
the shortest path to the nearest node. Send JOIN- 
REQ message towards that node via the shortest 
path. Change state TENTATIVE. 

so 

it the node receives a RETRY message via one of 
its links, then the node takes the following actions (path 
601 , FIG. 6): 

ignore the RETRY message if it does not contain 
state information. 



Forward JOI N-REQ message to next node. Change 25 
State = TENTATIVE. 



If current node is the final destination noted in the 
message, then return a RETRY message to the 
originator (Note that this condition may arise if the 
node changes its state from ACTIVE to IDLE during 
the time between the sending of the REQUEST 
message and JOIN-REQ message to node B.) 

An expanded version of the WAiT state is shown in 
FIGs. 5A : SB and 6. For FIGs. 5A and B , assume that 
a node received a REQUEST message containing the 
tupie <ID A ,CNTR A ,RC A > from node A. 

If the node also receives a REQUEST message 
from node B, <ID B ,CNTR B ,RC 3 >. Then the nods takes 
the following actions (path 501 ): 

Update the local time stamp counter. 

if the message had not been received via the short- 
est path, then send a REPLY to B, setting cost io -1 . 

If the message is received via the shortest path and 
A precedes B in time, then send a RETRY message 
to B. 

if the message is received via the shortest path and 
B precedes A in time, then send a RETRY message 
to A. Clear state information pertaining to A. Save 
information pertaining to B and forward REQUEST 
message. 

If the node receives a REPLY message via one of 



Clear the state information and forward the RETRY 
message towards the originator of REQUEST. 

Changs state IDLE. 

I? originator of REQUEST, then change siate - RE- 
TRY* 

as Increment retry count 

Wart for a random period of time, then resend the 
REQUEST message with She updated retry count 
value, (Note: The same counter value (CNTR) will 
40 be used to ensure fairness,} 

If the node receives a JOIN-REQ message from a 
node, e.g., node B, then the node proceeds as foilows 
(path 802, FIG. 8): 

46 

Change state = TENTATIVE. 

if next node information is available, then forward 
the JOIN-REQ message to the next node and send 
so a RETRY message to node A. 

If no rvm node, then send a RETRY message to- 
wards the originator ot the JOIN-REQ message. 

ss An expanded version of the TENTATIVE state of 
FIG 3. is snown in FIG. 7, :n which a node enters the 
TENTATIVE State after it receives a JOIN-REO mes- 
sage originated by another node, e.g., node A. if at that 



so 



lime, the node receives a REQUEST message from 
node B containing the tuple <!D 3 ,CNTR B , RC B >, then 
the receiving node proceeds in the following manner 
(path 701): 

If a REQUEST message is not received via the 
shortest path, then return a REPLY with cost = -i to 
the originator. Else, 

Update local counter value. 

Send RETRY message towards the originator of the 
message. 

II, on the other hand, the node receives a RETRY 
Message, then the nods takes the following actions 
(path 702): 

If RETRY matches JQiN-REQ, forward RETRY 
message back towards node A. 

Change state = IDLE. 

Ignore if RETRY message does not match JOIN- 
REQ. 

If the node otherwise receives a JOSN-ACK Mes- 
sage, then the node lakes the following actions (path 
703): 

Change State = ACTIVE. 
Forward Join-.Ack to node A. 
Clear ail state information. 

Update multicast tree information to include the link 
over which the JOIN-REQ was received. 

An expanded version of the ACTIVE state of FIG, 
3, is shown in FIG. 8, in which a node is already on the 
multicast tree. In that case, the node only responds to 
new requests and join requests. Other messages may 
be ignored. 

St a node in the active stats receives a REQUEST 
message from node 8 containing the tuple <ID B ,CN~ 
TR B , RC S >, then the receiving node takes the following 
action (path 801): 

If the REQUEST message is not received via the 
shortest path, then send REPLY message with cost 
~- -1 to the originator. Else. 

Update Soca! counter Value. 

Send a REPLY with cost = 0. 

If, on the other hand, the node receives a JOIN- 



REQ message from node 8. then the node returns a 
JOIN-ACK message to B (path 802). if the node other- 
wise receives a LEAVE message from node 8. then the 
node takes she following actions: 

5 

Update multicast tree information. 

If only one ACTIVE neighbor and the node is not 
member of multicast group, then send LEAVE mes- 
'0 sage to neighbor. 

Change state - IDLE. 

An expanded version of the RETRY State is shown 
is in FIG. 9. A node enters the RETRY state after sending 
a REQUEST message. Assume that node A is in the 
retry state and the associated tuple information is - 
<ID A ,CNTR A .RC A > : and that node A receives a RE- 
QUEST message from node 8 whose tuple information 
so is <ID B ,CNTR B ,RC B >. For that case, node A takes the 
following actions (path 901): 

If message is not on the shortest path, send a RE- 
PLY back with cost set to -1. Update local counter. 

ss 

if A precedes B in time, then send a RETRY mes- 
sage towards node B. 

If B precedes A in time, then save S's state infor- 
30 mat ion and forward the REQUEST message. Save 
A's information and stop A's retry timer (A cannot 
join the multicast group until S has joined). 

Change state = WAIT. (A is now waiting for 8) 

35 

If, on the other hand, a JOIN-REQ message is re- 
ceived from node B, then the node fakes the following 
actions (path 902): 

40 - Change state = TENTATIVE. Forward JOIN-REG 
message to next node on the path. 

Save A's information and wait. (A cannot resend 
REQUEST message until S has Joined multicast 
4S group). 

If Retry timer has expired, then increment Retry 
count and send REQUEST message containing the 
following tuple: 

so <ID A ,CNTR A> RG A >. The old value of CNTR A is 

used to ensure fairness. 

The foregoing may be readily Implemented In a net- 
work formed from a plurality of so-called Peer groups, 
ss in which a peer group is a group of network nodes form- 
ing a smaller network, in particular, a large network 
formed from a large number of nodes may be logically 
restructured to improve the efficiency of the number. 



Such restructuring entails forming nodes into groups 
each operating as a smaller network, in which connec- 
tion management functions are logically extended to 
each level of the network hierarchy. The state informa- 
tion is maintained at each physical node. In addition, 
each group is represented as a logical node at a higher 
level of the network hierarchy fay a peer group leader 
(PGL), The PGL maintains separate state information 
for that logicai node at that hierarchical level The logical 
nodes perform the same state transitions as the physical 
nodes at the lowest ievei of the network hierarchy, in 
that sense., our inventive protocol may be applied to 
such a network with the following modifications (exten- 
sions). 



i) A Joining Node prompts {requests) its PGL to en- 
ter the "Find" phase at the next higher level o! the 
hierarchy. At the logical level, pre-established virtu- 
al connections between logical nodes are used to 
send the REQUEST and REPLY messages. During 
the "Find" phase, the logical nodes may make a 
transition from the IDLE state to the WAIT state and 
RETRY state similar to the physical nodes. 

ii) It the PGL is already active at the higher ievei 
(which may mean that some other ACT! VE node ex- 
ists in the peer-group), then this Information is re- 
turned to the requesting node. On receipt ot the in- 
formation, the requesting node executes the proto- 
col to determine the nearest ACTIVE node within 
the peer-group. The ID of the nearest ACTIVE node 
{physical or logical) is returned to the lower level re- 
questing node If thecurrens level is the lowest level, 
then the requesting node enters the "Join" phase. 

iii) Otherwise, the PGL recursively executes the 
above steps at higher levels untii it reaches the top 
level of the hierarchy. At that level, the PGL enters 
the "Find" phase. At the end of the "Find" phase, 
the requesting node has the ID of the nearest AC- 
TIVE node. (Note that this ID may either be the 
physical ID ot the node within the same peer-group 
(single peer group case) or the logical ID ot a higher 
level node in a logical peer-group (multiple peer 
group case). 

Jam Pftm® 



Based on the available topological mtormatfon. a re- 
questing node determines the path to the nearest node. 
The path may not be complete if the nearest node is a 
logsca! node in a higher level, sogical peer-group. The 
determined path is stored in the form of a Designated 
Transit List (OTl), as discussed in the Private Network- 
Network Interface (PNNI) specification version TO. 
available from the ATM Forum, 2570 West Ei Cammo 



Real, Suite 304, Mountain View, California 94040-1313, 
which is hereby incorporated by reference. The DTL is 
embedded in the JOiN-REQ message before it is for- 
warded to the nearest node. On receiving: a JOiN-REQ 
■s message, a node executes the following protocol: 

1) If the node is already ACTIVE, it returns a JOIN- 
ACK message. The JOIN- ACK Is returned along 
the same path (in the reverse direction) to orsginat- 
?<5 ing node. 

ii) Else, if the DTL stack is not empty, then the 
JOIN-REQ message is forwarded to the next 
node based on the information available in the 

?5 DTL. (Note that new paths may be added to the 

DTL by ingress nodes, as explained In the 
above-mentioned reference. Also note that the 
JOIN-REQ and JOIN-ACK messages may be 
sent on network signaling channel. When the 

so JOIN-REQ or JOIN-ACK messages are sent 

across border links, the logical node at the ap- 
propriate level has to be informed so that the 
logical node cars make a state transition to the 
TENTATIVE or ACTIVE state respectively. This 

2$ is done by sending a copy of the JOiN-REQ or 

JOIN-ACK message to the appropriate logical 
node. 

)ii) If the DTL stack is empty, then the node en- 
ters the "Find" phase to determine the nearest 
so ACTIVE node. The nearest node information is 

then encoded as DTL and the message is far- 
warded to the nearest node. 

Similar actions are taken when a participating node 

35 leaves the multicast group. In this case a LEAVE mes- 
sage is sent to an ACT! VE neighbor nods, provided that 
the participant has only one ACTIVE neighbor The par- 
ticipant node then enters the iDLE state. The neighbor 
node may then forward the LEAVE message to its near- 

40 est neighbor If it is not a participant and has only one 
ACTIVE neighbor. When a LEAVE message ts sent 
across a border link, then a copy of the message is sent 
to the appropriate logical node, so that the global state 
of the node can be changed to the IDLE state. 

■*£ The extended protocol described immediately 
above may be further appreciated when discussed in 
conjunction with the examples illustrated in FIGs, 10 
through 13, in which each FIG. illustrates a network 
formed from three peer groups of network nodes (e.g., 

so. ATM switches) 201, 202 and 203. The nodes in peer 
group (a) 201 are respectively designated A.I through 
A.5, <b} 202 are respectively designated B.1 through B 
5 and (c) 203 ate respectively designated C.I through 
C.5. The dark (or filled in) node serves as the PQL for 

ss the respective peer group in each of FIGs. 10 through 
f 3, Assume for FIG. 10 that node A.3 wants to join a 
multicast group, and, therefore sends a request to that 
effect to its PGL (node A), which causes that PGL to 



enter the "Find 5 phase at the higher level as noted by 
the eilipse containing logical PGLs A, 8 and C. Since 
PGL A enters the highest lev©!, it sends a REQUEST 
message to the other members of its peer-group to de- 
termine who has the requested multicast information. 
Assume that PGL A determines that there are no mem- 
bers of the multicast in peer-groups 8 and C. This infor- 
mation is passed on to node A. 3 and She stats of nods 

A. 3 becomes ACTIVE. The multicast tree now consists 
of a single node A.3. Globally, the state machine for log- 
ical node A also makes a transition to the ACTIVE state. 
The ACTIVE nodes at each level are shown as boxes 
in FIG. 11. The participant nodes at each level are 
shown as lightly shaded boxes. 

Assume that node C.4 now wants to join the multi- 
cast group, and, therefore sends a request to its PGL 
(node C) to enter the "Find" phase. Node C, in response 
thereto, sends a REQUEST message to logical node B 
and logical node A. (Note that node C may enter the 
RETRY state if there is a concurrent Join request from 
logicai nods B.) I? there are no other requests, then only 
logical node A is ACTIVE and this information is sent to 
node C.4 by logical node C. This action completes the 
"Find" phase for node C.4, 

In the "Join" phase, node C.4 encodes a path to 
peer-group A as a DTL and forwards a JOI N-REQ mes- 
sage to peer-group A. The message enters peer-group 

B, across the border link (C.2-B.4}. Here, node B:4 is 
the ingress node and the DTL stack is not empty (step 
{si} of the "Join" phase). Node 6.4 identifies a path 
through its peer-group to peer-group A and appends the 
path to the DTL. it then towards the message towards 
peer-group A. Node B.4 also sends a copy ol the JOIN- 
REQ message So the PGL node B.I, which maintains 
the global state machine for logical node B Node B 1 
updates the global state machine of nods B to TENTA- 
TIVE slate. Assume that the message enters peer- 
group A across link (8.5-A.5). The DTL stack is now 
empty (step (iii) of the "Join" phase). Node A..5 upon re- 
ceipt of the message enters the "Find" phase to deter- 
mine the nearest node that should receive the message, 
i.e., node A.3. It then appends the path to node A 3 to 
the DTL and forwards the JOI N-REQ to node A.3. Node 
A 3, being in the ACTIVE state, replies to receipt of the 
message by returning a JOIN-ACK message (step (i) of 
the "Join" phase). The JOIN-ACK messages retraces 
the path followed by the JOfN-REQ message. When the 
JOhM-ACK crosses the border link (A.5-B.5), the state 
machine of logical node B is updated to the ACTIVE 
state. Logical nods G becomes ACTIVE when the JOIN- 
ACK message is sent across link (S.4--C2). The result- 
ing multicast tree Is shown as dotted lines in FIG. 12. 
Node 8.2 can now join the multicast tree by joining node 
3.4, as shown in FIG. 13. 

If participant A.3 leaves the multicast group, then ii 
sends a LEAVE message lo node A. S, which propagates 
the message to node B.S. Node A.5 also sends a copy 
of the LEAVE message to node A.1, so that the global 



state machine of logical peer-group A may be changed 
to the IDLE state. Node 8.5 also sends a LEAVE mes- 
sage to node B.4. However, the propagation of the latter 
message stops at node B.4 since that node has two AC- 

5 TlVE neighbors, nodes B.1 and C.2. The resulting free 
is shown in FIG. 14. Assume now node 8.2 similarly 
leaves the multicast group. In this instant the LEAVE 
message propagates to node C.4. Recall that when the 
LEAVE message is sent across link B.4-C.2, a copy is 

?o also sen! to node B. t so that the global state machine 
for the peer-group may be changed to IDLE state. The 
final tree consisting of only node C.4 is shown in FIG. 15. 



rs Claims 

1 , A method ot joining a multicast connection originat- 
ing from a source node distributing multicast infor- 
mation, said multicast connection being established 

20 m a network composed of a plurality of communica- 
tions nodes, saic method comprising the steps of 

at one of said nodes, responsive to receipt of a 
requssS so receive said multicast information. 

25 constructing at least one routing tree formed 

from selected paths so each of a number ot oth- 
er nodes identified in The tree and sending a 
message identifying said information to the se- 
lected nodes in accordance with the routing 

30 tree, and 

at said one node, responsive to receipt of a 
message identifying saio source node as being 
the originator of the identified information. 
ss sending a message containing a request to join 

multicast distribution of the identified informa- 
tion. 

2, The method of claim 1 further comprising the steps 
40 of 

at the source node, responsive to receipt of a 
message containing a request to join the multicast 
distribution of she identified information, returning 
an acknowledgment message to the originator of 
45 the message. 

3, Tne method of claim 1 further comprising the steps 
of 

so at the source node, responsive to receipt of a 

message containing a request to join the mul- 
ticast distribution of the identified information, 
constructing a network path tree rooted at the 
source node and extending to the node origi- 
ns' nating She message, and 

supplying the multicast information via the path 
tree rooted at the source node. 



4. The method of claim 3 wherein said multicast free 
includes at one intermediate node between the 
source node and the node originating the message 
and wherein said method further comprises the 
steps of 5 

at the intermediate node, responsive to receiv- 
ing from another one said nodes a message 
containing a request for said multicast informa- 
tion, returning to said other one of said nodes 10 
a reply message indicating that said intermedi- 
ate node can supply said multicast information., 
and 

at said other one of sasd nodes accumulating 15 

ail reply messages to its request for the multi- 
cast information and determining which of 
nodes returning a reply message is closest to 
said other one of said nodes, and 

so 

sending a message to join the multicast to the 
determined closest one of the nodes that re- 
turned a reply message to said other one of said 
nodes, 

2$ 

5. The method of ciasm 4 further comprising the step of 

at the closest one of the nodes, responsive to 
receipt of the join message and thereafter respon- 
sive to receipt of multicast information via the. path 
tree rooted at the source node, sending a copy of 30 
the received multicast information to the other one 
of said nodes, 

S, The method of claim 5 wherein said intermediate 
node ss sasd closest one ot ?he nodes and wherein 3S 
said method further comprises the steps of 

at said intermediate node, responsive to re- 
ceiving from said one node a message addressed 
to said source node and requesting a termination of 
the sending of the mu Iticast information to said one 40 
node, terminating the sending of the multicast infor- 
mation to said one node and continuing to supply 
the multicast information as it is. received to said oth- 
er one of sasd nodes. 

46 

7. The method of claim 5 wherein said intermediate 
node is said closest one of the nodes and wherein 
said method further comprises the steps of 

at the intermediate node, responsive to re- 
ceiving from said other one of sard nodes a mes- so 
sage addressed So said source node and requesting 
a termination of the sending of the multicast infor- 
mation to sasd other one of sasd nodes, terminating 
the sending of the multicast information to said oth- 
er one of said nodes, and responsive to having no ss 
other recipient for said multicast information, send- 
ing She received termination message to the source 
node. 



®» A method of joining a multicast connection originat- 
ing from a source node distributing multicast infor- 
mation, sasd multicast connection being established 
in a network composed of a plurality of communica- 
tions nodes, said method comprising the steps of 

at a network node, responsive to receiving from 
first and second other ones of the network 
nodes respective message requests to join the 
multicast, determining as a function of a prede- 
termined parameter, which one of the first and 
second nodes is to be connected first to She 
multicast connection and sending a wait mes- 
sage to the other one of the first and second 
nodes, 

forwarding the message received from said one 
of said first and second nodes over a path con- 
tained in that message, and 

thereafter., responsive to receipt of multicast in- 
formation from a source via a path rooted at the 
source, supplying fhe multicast information So 
said one of said first and second nodes 

9. The method of claim 8 further comprising the steps 
of 

at said other one of said first and second nodes, 
response to receipt of the wait message, wait- 
ing a predetermined period of time, and 

at the expiration of that period of time, again 
sending a message requesting receipt of the 
multicast information. 

1 0. The method of claim 9 further comprising she step of 

at said network node, responsive to receipt of 
the request message from said other one of said 
first and second nodes, supplying said multicast in- 
formation to said other one of said first and second 
nodes as if ss received from the source. 

11 . The method of claim 9 further comprising the steps 
of 

at said network node, responsive to receiving 
from said one node of said first and second modes 
a message addressed to said source node and re- 
questing a termination of the sending of the multi- 
cast information to said one of said first and second 
nodes, terminating the sending of the multicast in- 
formation to that node and continuing to supply the 
multicast information as it is received to said other 
one of said first and second nodes 

12. The method of claim 9 further comprising the steps 
of 

at said network node, responsive to receiving 



from said other one of said first and second nodes 
a message addressed to said source node and re- 
questing a termination of the sending of the rouiU- 
cast information to said other one of said first and 
second nodes, terminating the sending of the mul - 
ticast information to said that node, and responsive 
to having no other recipient for said multicast infor- 
mation, sending the received message requesting 
termination to the source node. 
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Method for joining a multicast connection. Receiving a. 
r-equeit to f-ece-lve awUicast information. Construct. i ng a 
'■out i and ieod-no. s t^ssa^ to v.^iscted poces in 
accordance with the routing tree 



Method of joining a multicast connection. Receiving a join 
message from a Mri.t a^d s-'scortd node. Dep«?nd1fsg on a 
predetermined parameter connecting one node sred ssniipg a 
K.jit src-ssagd to the second node. 



